The present invention relates to systems and methods for software management and, more particularly, to systems, methods, and computer program products for provisioning or distributing software products, such as open source software products.
Managing and customizing open source software systems, such as the Linux operating system, has been hampered by the very heart of system maintenance: the software management system. With the current packaging systems and tools available for Linux, local changes to source code and configuration files have typically fallen into users' or administrators' hands for safekeeping, which may require manual synchronization when changes are made by the operating system distributor.
Traditional package management systems, such as the RPM package manager (RPM) and the Debian package management system (dpkg) are generally considered to provide an improvement over the previous regime of installing from source or binary tar archives. Traditional package management systems typically use simple version numbers to allow the different package versions to be sorted into “older” and “newer” packages, adding concepts, such as epochs, to work around version numbers that do not follow the packaging system's ideas of how they are ordered. While the concepts of “newer” and “older” seem simple, they may break down when multiple streams of development are maintained simultaneously using the package model. For example, a single version of a set of sources can yield different binary packages for different versions of a Linux distribution. A simple linear sorting of version numbers cannot represent this situation, as neither of those binary packages is newer than the other; the packages simply apply to different contexts.
Traditional package management systems typically provide no facilities for coordinating work between independent repositories.                Repositories may have version clashes; the same version-release string means different things in different repositories. Repositories can even have name clashes—the same name in two different repositories might not mean the same thing.        There may be no way to identify which distribution, let alone which version of the distribution, a package is intended and built for.For example, of two packages available on the Internet, which is newer, aalib-1.4.0-5.1fc2.fr or aalib-1.4.0-0-fdr.0.8.rc5.2? One is from the freshrpms repository, and the other is from the fedora.us repository. Which package should users apply to their systems? Does it depend on which version of which distribution they have? How are the two packages related? Are they related at all? This may not be a problem in a disconnected world. However, when packages are installed from multiple sources, it can be hard to tell how to update them—or even what it means to update a package. An administrator may have to rely on memory of where a package is fetched from to look in the right repository. Once you look there, it may not be obvious which packages are intended for the particular version of the distribution you have installed. Automated tools for fetching packages from multiple repositories have increased the number of independent package repositories over the past few years, which has generally made the confusion more and more evident.        
The automated tools helped exacerbate this problem (although they did not create it); they have generally not been able to solve it because the packages typically do not carry enough information to allow the automated tools to do so.
Traditional package management typically does not closely associate source code with the packages created from it. The binary package may include a hint about a filename to search for to find the source code that was used to build the package, but there generally is no formal link contained in the packages to the actual code used to build the packages. Many repositories carry only the most recent versions of packages. Therefore, even if you know which repository you got a package from, you may not be able to access the source for the binary packages you have downloaded because it may have been removed when the repository was upgraded to a new version. (Some tools help ameliorate this problem by offering to download the source code with binaries from repositories that carry the source code in a related directory, but this is only a convention and may be limited.)
Traditional package management typically does not provide a globally unique mechanism for avoiding package name, version, and release number collisions; all collision-avoidance is typically done by convention and is generally successful only when the scope is sufficiently limited. Package dependencies (as opposed to file dependencies) may suffer from this; they are generally valid only within the closed scope of a single distribution; they generally have no global validity.
It can also be difficult for users to find the right packages for their systems. Both SUSE and Fedora provide RPMs for version 1.2.8 of the iptables utility; if a user found release 101 from SUSE and thought it was a good idea to apply it to Fedora Core 2, they may break their systems.
Traditional packaging systems typically have a granular definition of architecture, not reflecting the true variety of architectures available. They typically try to reduce the possibilities to common cases (i386, i486, i586, i686, x86—64, etc.) when, in reality, there are many more variables. But to build packages for many combinations may mean storing a new version of the entire package for every combination built, and then may require the ability to differentiate between the packages and choose the right one. While some conventions have been loosely established in some user communities, many times customization has required individual users to rebuild from source code, whether they want to or not. In addition, many packaging systems build their source code in an inflexible way; it is not easy to keep local modifications to the source code while still tracking changes made to the distribution.
Traditional package management systems may allow the packager to attach arbitrary shell scripts to packages as metadata. These scripts are run in response to package actions, such as installation and removal. This approach may create problems such as the following:                Bugs in scripts are often catastrophic and may require complicated workarounds in newer versions of packages. This can arbitrarily limit the ability to revert to old versions of packages.        Most of the scripts are boilerplate that is copied from package to package. This may increase the potential for error, both from faulty transcription (introducing new errors while copying) and from transcription of faults (preserving old errors while copying).        Triggers (scripts contained in one package but run in response to an action done to a different package) may introduce levels of complexity that defy reasonable QA efforts.        Scripts may not be able to be customized to handle local system needs.        Scripts embedded in traditional packages may fail when a package written for one distribution is installed on another distribution.        